Sergey Anohin <Sergey.Anohin@p1.f10.n5034.z2.fidonet.org> wrote: AK>> А надо было - 16 (или крутить настройки innodb, но это чревато). А, да - AK>> логи AK>> пишутся линейно, их трогать не надо. SA> короче стопим mysql копируем, удаляем, заливаем обратно? можно не заливать а перемонтировать клон вместо основного сразу. по дороге выставив ему блок в 16
SA> База данных осуществляет чтение в произвольном порядке, который нельзя SA> предсказать. а диск у нас -круглый, и данные обычно стараются раскладыватьлинейно методом preallocate. Причем чтение большошго страйпа гораздо быстрее чем позиционирование голов и люыбе другие действия с диском - поэтому читаем мы - страйп, и в arc помещаем весь - он уже прочитан, чего его на пол-то кидать Дальше он либо при заполнении улетает при lru, либо, куда более вероятно, за ним приходят, а его читать уже не надо. При линейном копировании - сам понимаешь.
SA> ZFS кэширует данные в ARC, используя свободную оперативную память. Поскольку SA> страницы InnoDB уже кэшируются в буфер пуле, отключим кэширование файлов данных SA> InnoDB: SA> # zfs set primarycache=metadata data/mysql/ibdata SA> или тут нелогично? учитывая что префетч можно запретить только глобально - нелогично. если тольк у тебя не один mysql (и вот копировать его ты тоже не планируешь, только clone)
SA> тут надо передеывать, ибо там как оказалось мало полезного, потому что SA> у меня innodb_file_per_table=1; это значит что 16k надо было включать уровнем они и должны сжимать, это повторяющиеся данные. Да 16 при этом включать не надо, сжатие использует блоки переменной длинны.
> Alex
--- ifmail v.2.15dev5.4 * Origin: Demos online service (2:5020/400)
